home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940228.txt < prev    next >
Internet Message Format  |  1994-11-13  |  5KB
  1. Date: Thu, 13 Oct 94 04:30:02 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: List
  6. Subject: TCP-Group Digest V94 #228
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Thu, 13 Oct 94       Volume 94 : Issue  228
  11.  
  12. Today's Topics:
  13.                      Antenna Switching Time [fwd]
  14.                          compileing wnos-94xx
  15.  
  16. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  17. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  18. Problems you can't solve otherwise to brian@ucsd.edu.
  19.  
  20. Archives of past issues of the TCP-Group Digest are available
  21. (by FTP only) from UCSD.Edu in directory "mailarchives".
  22.  
  23. We trust that readers are intelligent enough to realize that all text
  24. herein consists of personal comments and does not represent the official
  25. policies or positions of any party.  Your mileage may vary.  So there.
  26. ----------------------------------------------------------------------
  27.  
  28. Date: 13 Oct 94 00:41:00 PST
  29. From: "UCLA::CORBIN" <CORBIN%UCLA.decnet@physics.ucla.edu>
  30. Subject: Antenna Switching Time [fwd]
  31.  
  32. Hi Folks, the following is a forward for Mike, wd6ehr
  33.  
  34. =====================================================================
  35.  
  36. Date: Mon, 10 Oct 94 14:14:05 PST
  37. From: "Mike Curtis" <wd6ehr@wd6ehr.ampr.org>
  38. Message-ID: <7613.wd6ehr@wd6ehr.ampr.org>
  39. To: wy6s@wa6epd.ampr.org
  40. Reply-to: mike@wd6ehr.ampr.org
  41. Subject: Please post to TCPGROUP
  42. Comments: Laissez les bons temps rouler
  43.  
  44. KD5I writes:
  45.  
  46. (addressing excessive keyup delay @ 9600 and 19k2)
  47.  
  48. > I experimented with the tx delay and found that this radio takes about 0.4
  49. > seconds to go from receive to transmit!
  50. >
  51. > At 1200 baud .4 seconds is not a real problem
  52. >
  53. >                                karl k5di
  54.  
  55. It might not SEEM like a problem, based only on lost data time, but it is a
  56. tremendous problem when you consider you have nearly a half second of de facto
  57. hidden terminal syndrome when your rig plugs its ears before ready to tell the
  58. channel that it's using it.
  59.  
  60. If you're point to point with just a single station, or channel capacity is
  61. below the Aloha effect 11% usage, this is not a big deal.  But if you're on a
  62. busy channel, retries will be the rule rather than the exception.
  63.  
  64. Even at 300 baud half duplex, it is important to get your transmitter putting
  65. out RF as soon as possible.
  66.  
  67. Of course, if you're running full duplex, this is a non issue.
  68.  
  69. On duplex repeaters, where "there are no hidden terminals", certain users
  70. invariably retry heavily.  Without exception, these have self-induced "hidden
  71. terminal syndrome" from slow rigs and/or running multiple ports on the same
  72. band.  I've not only seen this, but have received several reports from others.
  73.  
  74. A good test is to set retry low, i.e. 2 oe 3, and test over a good RF path
  75. that's not real busy.  If you consistently retry out, it's likely that
  76. something is wrong with your station.  It could be deviation/splatter (I've
  77. monitored some "plug and play" 1200 baud that's close to 100 kHz wide @ -40
  78. dB) or other transmitter related problems, receiver front end overload,
  79. "intermod" or generic thereof, a slow T/R or R/T turnaround, etc.
  80.  
  81. Many HT's are notorious for receiver overload, especially the "scanner"
  82. variety that receives from DC to light.  What kind of front end selectivity do
  83. you think they build into these?  Also, these are designed for rubber ducks at
  84. 5', not megagain antennas at 50'.  Many of these also have slow keyup and/or
  85. recovery times.
  86.  
  87. Regarding 9600 baud, what I have found is that long TXDelays also increase bit
  88. error rate, all other factors being equal.  Why, I don't really know, nor am I
  89. interested in fixing something I view as inherently undesireable.
  90.  
  91. MORAL OF THE STORY: As long as your radio takes too long to key up or recover,
  92. it's not going to work all that well for packet.
  93.  
  94. This is often easy to fix.  Many times, it is caused by circuits normally
  95. turned off when inactive.  Some rigs can be speeded up by running the low
  96. level transmitter sections constantly, and turning on the receiver full time.
  97. Not much fun to listen to, but who listens to BRAAAPing (or hissing) that
  98. would care one way or the other about hearing themselves :-)
  99.  
  100. Also, does anyone know if the HSMODEM (high speed modem) newsgroup is still in
  101. existence?
  102.  
  103. --
  104. 73, Mike
  105.  
  106. ------------------------------
  107.  
  108. Date: Thu, 13 Oct 94 08:31:27 EWT
  109. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  110. Subject: compileing wnos-94xx
  111.  
  112. >From: iw1cfl@ik1qld-10.ampr.org
  113.  
  114. >Hello Barry,
  115. >I have tried unsuccesfully to compile the last wnos version.
  116. >I use BC 3.1.
  117. One basic mistake already The code is only Designed to compile
  118. with Borland C++ Version 2.00
  119. Due to too many problems with borland lib's and bugs with them
  120. and the return of the memory leak if you dont use version 2.00
  121. we dont compile wnos in any other compiler.
  122. maybe later we convert it to use the GCC GNU C++ compiler
  123. I know of one users who is porting the code here at work to use
  124. the SUN OS 4.1.3 rev C  and hope to run wnos on unix.
  125.  
  126. >Thanks in advance.
  127.  
  128. >Mike
  129.  
  130. sorry cant help.!
  131. Barry
  132.  
  133. ------------------------------
  134.  
  135. End of TCP-Group Digest V94 #228
  136. ******************************
  137.